Determining Location Based on Measurements of Device Orientation

ABSTRACT

A method implemented by one or more processors may include determining a rotation between a client device frame and a world frame, determining a rotation between an average gravity aligned (AGA) frame of the client device and the client device frame, performing step detection of the client device, and determining a change in orientation from a first detected step to a second detected step. In one example, computing the change in orientation includes determining a rotation between a horizontally projected AGA (HPAGA) frame and the AGA frame, determining a rotation between the world frame and the HPAGA frame, and determining the change in orientation by using the rotation between the world frame and the HPAGA frame. The method may also include determining, using the computed change in orientation, pedestrian dead reckoning data of the client device over a time period, and determining an output location estimate of the client device using the pedestrian dead reckoning data.

CROSS REFERENCE TO RELATED PATENT APPLICATION

The present application claims priority to U.S. patent application Ser.No. 14/815,500, filed Jul. 31, 2015, the contents of which are hereinincorporated by reference in their entirety. U.S. patent applicationSer. No. 14/815,500 claims priority to U.S. provisional patentapplication No. 62/032,522, filed on Aug. 1, 2014, the contents of whichare herein incorporated by reference in their entirety.

BACKGROUND

Unless otherwise indicated herein, the materials described in thissection are not prior art to the claims in this application and are notadmitted to be prior art by inclusion in this section.

A location of a computing device can be determined using differenttechniques, such as techniques based on Global Positioning System (GPS)data or on data associated with a wireless access point (e.g., acellular base station or an 802.11 access point). In one example, acomputing device may receive a GPS signal and responsively determine itsposition on the face of the Earth (e.g. an absolute location). Inanother example, a computing device may receive a signal from either acellular base station or an 802.11 access point. The cellular basestation or an 802.11 access point may estimate an exact location. Basedon the location of either the cellular base station or an 802.11 accesspoint, the computing device can calculate its position.

Within some instances, a localization of a computing device may occurvia use of data from multiple different networks. Many location-basedservices can be provided to a computing device based on determining thelocation of the mobile computing device.

SUMMARY

In one example, a method performed, at least in part, by one or moreprocessors of a computing device, includes determining a rotationbetween a client device frame and a world frame, determining a rotationbetween an average gravity aligned (AGA) frame of the client device andthe client device frame, performing step detection of the client device,and determining a change in orientation from a first detected step to asecond detected step. In this example, computing the change inorientation further includes determining a rotation between ahorizontally projected AGA (HPAGA) frame and the AGA frame, anddetermining a rotation between the world frame and the HPAGA frame.Determining the rotation between the world frame and the HPAGA frame mayuse one or more of the rotation between the client device frame and theworld frame, the rotation between the AGA frame and the client deviceframe, or the rotation between the HPAGA frame and the AGA frame.Computing the change in orientation may also include determining thechange in orientation by using the rotation between the world frame andthe HPAGA frame. The example method may also include determining, usingthe computed change in orientation, pedestrian dead reckoning data ofthe client device over a time period, and determining an output locationestimate of the client device using the pedestrian dead reckoning data.

Another example is directed to a non-transitory computer-readable mediumhaving stored therein instructions, that when executed by one or moreprocessors of a computing device, cause the computing device to performvarious functions. In one example, the functions include determining arotation between a client device frame and a world frame, determining arotation between an average gravity aligned (AGA) frame of the clientdevice and the client device frame, performing step detection of theclient device, and determining a change in orientation from a firstdetected step to a second detected step. In this example, computing thechange in orientation further includes determining a rotation between ahorizontally projected AGA (HPAGA) frame and the AGA frame, anddetermining a rotation between the world frame and the HPAGA frame.Determining the rotation between the world frame and the HPAGA frame mayuse one or more of the rotation between the client device frame and theworld frame, the rotation between the AGA frame and the client deviceframe, or the rotation between the HPAGA frame and the AGA frame.Computing the change in orientation may also include determining thechange in orientation by using the rotation between the world frame andthe HPAGA frame. The example method may also include determining, usingthe computed change in orientation, pedestrian dead reckoning data ofthe client device over a time period, and determining an output locationestimate of the client device using the pedestrian dead reckoning data.

A further example provides a system that includes a processor and acomputer-readable medium. The computer-readable medium is configured tostore instructions, that when executed by the at least one processor,cause the system to perform functions. In one example, the functionsinclude determining a rotation between a client device frame and a worldframe, determining a rotation between an average gravity aligned (AGA)frame of the client device and the client device frame, performing stepdetection of the client device, and determining a change in orientationfrom a first detected step to a second detected step. In this example,computing the change in orientation further includes determining arotation between a horizontally projected AGA (HPAGA) frame and the AGAframe, and determining a rotation between the world frame and the HPAGAframe. Determining the rotation between the world frame and the HPAGAframe may use one or more of the rotation between the client deviceframe and the world frame, the rotation between the AGA frame and theclient device frame, or the rotation between the HPAGA frame and the AGAframe. Computing the change in orientation may also include determiningthe change in orientation by using the rotation between the world frameand the HPAGA frame. The example method may also include determining,using the computed change in orientation, pedestrian dead reckoning dataof the client device over a time period, and determining an outputlocation estimate of the client device using the pedestrian deadreckoning data.

These as well as other aspects, advantages, and alternatives, willbecome apparent to those of ordinary skill in the art by reading thefollowing detailed description, with reference where appropriate to theaccompanying figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a block diagram of an example communication systemaccording to an embodiment of the present disclosure.

FIG. 2 illustrates a block diagram of an example computing deviceaccording to an embodiment of the present disclosure.

FIG. 3 illustrates a block diagram of an example computing deviceaccording to another embodiment of the present disclosure.

FIG. 4 is a flow chart of an example method for determining a locationand/or movement of a device.

FIG. 5 is a flow chart of another example method for determining andusing one or more orientations associated with a device.

FIG. 6 illustrate different reference frames for determining one or moreorientations associated with a device.

FIG. 7 is block flow diagram that illustrates relationships betweenframes and rotations, in accordance with an embodiment of the presentdisclosure.

FIG. 8 is a flow chart of another example method for determining andusing one or more orientations associated with a client device.

FIG. 9 is block flow diagram that illustrates relationships betweenframes, rotations, and/or parameters in accordance with an embodiment ofthe present disclosure.

FIG. 10 is a block diagram that conceptually illustrates an examplesystem for determining location estimates of a device, and optionally,maps of observed data received from the device.

DETAILED DESCRIPTION

The following detailed description describes various features andfunctions of the disclosed systems and methods with reference to theaccompanying figures. In the figures, similar symbols identify similarcomponents, unless context dictates otherwise. The illustrative systemand method embodiments described herein are not meant to be limiting. Itmay be readily understood that certain aspects of the disclosed systemsand methods can be arranged and combined in a wide variety of differentconfigurations, all of which are contemplated herein.

I. Overview

Within examples, a number of logs of data or traces of data are receivedfrom one or more devices. The data may include a variety of informationcollected by one or more sensors of the devices. These sensors mayinclude a GPS, accelerometer, gyroscope, inertial measurement unit(IMU), barometer, magnetometer, and WIFI signal strength sensor, as justsome examples. The present disclosure relates to techniques forprocessing orientation data in the traces of data, such as from anaccelerometer, gyroscope, and/or magnetometer, to determine anorientation of the device and/or a user of the device. The device and/oruser orientation may be determined with respect to a frame of referencerelative to the earth or a world frame.

The present disclosure also relates to using the device/user orientationto determine a walking direction or pedestrian dead reckoning associatedwith the device. In one aspect, a computing device, such as a cellularphone, may use pedestrian dead reckoning calculations to localize aposition of the device and to build a map of a location of the deviceand of a user of the device. Generally, dead reckoning calculations linkpositions of devices between two steps. For instance, a first step maybe at time t, and a second step may be at t+1. The second step is onaverage likely to be around 3 ft in front of the first step, and anangle of turn or change in orientation between the first and secondsteps can be determined using, for example, gyroscope data.

An example dead reckoning determination may be performed to determine anestimation of a current position of the computing device based on aprevious position of the computing device, an estimated speed over anelapsed time, and an orientation or direction of travel of the computingdevice. Within examples, information indicating a previous position maybe received from a server that calculates or determines the informationdue to communication with a computing device, or from sensors of thecomputing device including a GPS sensor. The previous position may alsobe derived or calculated from a number of data points such as GPSlocation determinations, or WIFI scans and associated WIFI mappings. Theestimated speed can also be received from a server, or derived orcalculated from position determinations over an elapsed time or based onother data over the elapsed time including outputs of a pedometer, forexample. Using a known or estimated distance traveled (as derived orcalculated from outputs of a pedometer, derived from outputs of anaccelerometer inferring a step has been taken, or from other sensordata), a speed can be determined based on the elapsed time. Theorientation or direction of travel of the computing device may bedetermined from data received from a server, or from sensors on-boardthe computing device such as a magnetometer or compass, for example. Anyavailable information may be used to infer an orientation or a directionof travel including a fusion of accelerometer, gyroscope, and optionallymagnetometer data, for example. In still other examples, other availableinformation can be used to provide further estimates (directly orindirectly) as to direction of travel, including WIFI scans received intraces that may give information as to a position and heading of adevice and/or user.

The dead reckoning calculation can be performed to determine anestimation of the current position of the computing device. As anexample, an accelerometer of the computing device can be used as apedometer and a gyroscope or magnetometer as an orientation or compassheading provider. Each step of a user of the computing device causes aposition to move forward a fixed distance in an orientation directionmeasured by the compass. Accuracy may be limited by precision of thesensors, magnetic disturbances inside structures of the computingdevice, and unknown variables such as carrying position of the computingdevice and stride length of the user. However, the estimate of thecurrent position can be determined in this manner. The presentdisclosure provides additional techniques for determining orientationdata.

Further, the present disclosure relates to fusing or linking the deadreckoning calculations with other constraints, such as Wi-Fi scan data,GPS readings, and/or magnetic field data, to determine and refine a mapand position of a device and/or user of the device. Generally, acomputing device, such as a mobile phone or a server device, can performfusion or linking of various constraints, such as dead reckoningcalculations and magnetic field information in a tight-coupling manneror loose-coupling manner. Tight-coupling calculations may providerelatively high accuracy, but may also be relativelycomputationally-intensive, and may be prone to convergence to anincorrect solution. Loose-coupling calculations are generally lesscomputationally-intensive than tight-coupling calculations, and may bemore robust but may provide lower accuracy than tight-couplingcalculations. In examples disclosed herein, the present disclosureadapts loose-coupling calculations to estimate the orientation of thedevice and/or the user of the device with respect to the world frame.

The device orientation may also be used to rotate or otherwise processmagnetic field information according to a frame of reference of thedevice with respect to the world. The computing device may use theprocessed magnetic field information, and perhaps with otherconstraints, to determine a location of the device and/or to build a mapof an area around the device.

Further, the computing device may present a map on a display, and showthe device location on the map, or otherwise generate information andinstructions for providing such a display. The location of the devicemay also be used in location-based services, such as to narrow anInternet search to an area that is nearby the client device location, topersonalize “local” news and/or weather updates or information sent tothe device, to direct emergency calls (e.g., 911 call-services) to anappropriate or closest call handling service, and the like.

II. Example Systems and Devices

Referring now to the figures, FIG. 1 illustrates an examplecommunication system 100 in which an example method may be implemented.In FIG. 1, a client device 102 may communicate with a server 104 via oneor more wired and/or wireless interfaces. The client device 102 and theserver 104 may communicate within a network. Alternatively, the clientdevice 102 and the server 104 may each reside within a respectivenetwork.

The client device 102 may be any type of computing device or transmitterincluding a laptop computer, a mobile telephone, a tablet computingdevice, and the like, that is configured to transmit data 106 to and/orreceive data 108 from the server 104 in accordance with the method andfunctions described herein. The client device 102 may include a userinterface, a communication interface, a processor, and data storagecomprising instructions executable by the processor for carrying out oneor more functions relating to the data sent to, and/or received by, theserver 104. The user interface may include buttons, a touchscreen, amicrophone, and/or any other elements for receiving inputs, as well as aspeaker, one or more displays, and/or any other elements forcommunicating outputs.

The server 104 may be any entity or computing device arranged to carryout the method and computing device functions described herein. Further,the server 104 may be configured to send data 108 to and/or receive data106 from the client device 102. The server 104 may include a locationmodule 110 which may be configured to process the data 106 received fromthe client device 102 to determine locations (present and historical)associated with the client device 102.

The data 106 received by the server 104 from the client device 102 maytake various forms. For example, the client device 102 may provideinformation indicative of a location of the client device 102, movementof the client device 102, or inputs from a user of the client device102. The server 104 may then process the data 106 to identify a locationhistory that matches to the received data.

The data 108 sent to the client device 102 from the server 104 may takevarious forms. For example, the server 104 may send to the client device102 an indication of location, updated location history information, orinformation based on the locations of the device.

FIG. 2 illustrates a schematic drawing of an example device 200. In FIG.2, the computing device takes a form of a client device 200. In someexamples, some components illustrated in FIG. 2 may be distributedacross multiple computing devices. However, for the sake of example, thecomponents are shown and described as part of one example client device200. The client device 200 may be or include a mobile device, desktopcomputer, email/messaging device, tablet computer, or similar devicethat may be configured to perform the functions described herein.

In some implementations, the client device 200 may include a deviceplatform (not shown), which may be configured as a multi-layered Linuxplatform. The device platform may include different applications and anapplication framework, as well as various kernels, libraries, andruntime entities. In other examples, other formats or systems mayoperate the client device 200 as well.

The client device 200 may include an interface 202, a wirelesscommunication component 204, a cellular radio communication component206, a global position system (GPS) 208, one or more sensors 210, datastorage 212, and a processor 214. Components illustrated in FIG. 2 maybe linked or coupled together by a communication link or bus 216. Theclient device 200 may also include hardware to enable communicationwithin the client device 200 and between the client device 200 andanother computing device, such as the server 104 of FIG. 1. The hardwaremay include transmitters, receivers, and antennas, for example.

In one example, the interface 202 is configured to allow the clientdevice 200 to communicate with another computing device, such as aserver. Thus, the interface 202 may be configured to receive input datafrom one or more computing devices, and may also be configured to sendoutput data to the one or more computing devices. In some examples, theinterface 202 may also maintain and manage records of data received andsent by the client device 200. In other examples, records of data may bemaintained and managed by other components of the client device 200. Theinterface 202 may also include a receiver and transmitter to receive andsend data. In other examples, the interface 202 may also include auser-interface, such as a keyboard, microphone, touchscreen, etc., toreceive inputs as well.

The wireless communication component 204 may be a communicationinterface that is configured to facilitate wireless data communicationfor the client device 200 according to one or more wirelesscommunication standards. For example, the wireless communicationcomponent 204 may include a WIFI communication component that isconfigured to facilitate wireless data communication according to one ormore IEEE 802.11 standards. As another example, the wirelesscommunication component 204 may include a Bluetooth communicationcomponent that is configured to facilitate wireless data communicationaccording to one or more Bluetooth standards. Other examples are alsopossible.

The processor 214 may be configured to determine one or moregeographical location estimates of the client device 200 using one ormore location-determination components, such as the wirelesscommunication component 204, the cellular radio communication component206, and/or the GPS 208. For instance, the processor 214 may use alocation-determination algorithm to determine a location of the clientdevice 200 based on a presence and/or location of one or more knownwireless access points within a wireless range of the client device 200.In one example, the wireless communication component 204 may determinethe identity of one or more wireless access points (e.g., a MAC address)and measure an intensity of signals received (e.g., received signalstrength indication) from each of the one or more wireless accesspoints. The received signal strength indication (RSSI) from each uniquewireless access point may be used to determine a distance from eachwireless access point. The distances may then be compared to a databasethat stores information regarding where each unique wireless accesspoint is located. Based on the distance from each wireless access point,and the known location of each of the wireless access point, a locationestimate of the client device 200 may be determined.

In another instance, the processor 214 may use a location-determinationalgorithm to determine a location of the client device 200 based onnearby cellular base stations. For example, the cellular radiocommunication component 206 may be configured to at least identify acell from which the client device 200 is receiving, or last received,signal from a cellular network. The cellular radio communicationcomponent 206 may also be configured to measure a round trip time (RTT)to a base station providing the signal, and combine this informationwith the identified cell to determine a location estimate. In anotherexample, the cellular communication component 206 may be configured touse observed time difference of arrival (OTDOA) from three or more basestations to estimate the location of the client device 200.

In still another instance, the processor 214 may use alocation-determination algorithm to determine a location of the clientdevice 200 based on signals sent by GPS satellites above the Earth. Forexample, the GPS 208 may be configured to estimate a location of themobile device by precisely timing signals sent by the GPS satellites.

In other examples, the processor 214 may use a location-determinationalgorithm to determine a location of the client device 200 basedBluetooth wireless signals. The Bluetooth signals can be compared to amap of Bluetooth devices, and a measurement probability map in which agiven Bluetooth wireless signal is estimated to be received can bedetermined. Within examples, Bluetooth devices may include staticdevices (e.g., such as Bluetooth Low Energy (BLE) beacons) that emitsignals to nearby devices. Each Bluetooth device will have a range inwhich signals can be emitted, and the range can be used as a measurementprobability map as the constraint for locations of the device.

In still other examples, the processor 214 may use alocation-determination algorithm to determine a location of the clientdevice 200 based on magnetic field signals. For example, ambientmagnetic fields are present in environments, and include disturbances oranomalies in the Earth's magnetic field caused by pillars, doors,elevators in hallways, or other objects that may be ferromagnetic innature, A device may measure a magnetic field, and when such magneticfield measurements are present in the logs of data, the measurements canbe compared to a map of magnetic field signal strength for a givenlocation, and a measurement probability map in which a given magneticfield signal strength corresponds to a signal strength of the magneticfield signal can be determined and used as the constraint to determine alocation of the client device.

In some examples, the processor 214 may use a location-determinationalgorithm that combines location estimates determined by multiplelocation-determination components, such as a combination of the wirelesscommunication component 204, the cellular radio component 206, and theGPS 208.

The sensor 210 may include one or more sensors, or may represent one ormore sensors included within the client device 200. Example sensorsinclude an accelerometer, gyroscope, magnetometer, pedometer, barometer,light sensors, microphone, camera, or other location and/orcontext-aware sensors.

The processor 214 may also use a location-determination algorithm thatfuses data from the one or more sensors 210. For instance, the processor214 may be configured to execute a dead reckoning algorithm that uses alog of sensor data as inputs to the dead reckoning algorithm todetermine an estimated trajectory or pedestrian dead reckoning of theclient device and associated user.

The data storage 212 may store program logic 218 that can be accessedand executed by the processor 214. The data storage 210 may also storecollected sensor data 220 that may include data collected by any of thewireless communication component 204, the cellular radio communicationcomponent 206, the GPS 208, and any of sensors 210.

The communication link 216 is illustrated as a wired connection;however, wireless connections may also be used. For example, thecommunication link 216 may be a wired serial bus such as a universalserial bus or a parallel bus, or a wireless connection using, e.g.,short-range wireless radio technology, communication protocols describedin IEEE 802.11 (including any IEEE 802.11 revisions), or Cellulartechnology, among other possibilities.

The illustrated client device 200 in FIG. 2 includes an additionalprocessor 222. The processor 222 may be configured to control otheraspects of the client device 200 including displays or outputs of theclient device 200 (e.g., the processor 222 may be a GPU). Examplemethods described herein may be performed individually by components ofthe client device 200, or in combination by one or more of thecomponents of the client device 200. In one instance, portions of theclient device 200 may process data and provide an output internally inthe client device 200 to the processor 222, for example. In otherinstances, portions of the client device 200 may process data andprovide outputs externally to other computing devices.

FIG. 3 illustrates a schematic drawing of another example computingdevice. In FIG. 3, the computing device takes a form of a server 300. Insome examples, some components illustrated in FIG. 3 may be distributedacross multiple servers. However, for the sake of example, thecomponents are shown and described as part of one example server 300.The server 300 may be a computing device, cloud, or similar entity thatmay be configured to perform the functions described herein.

The server 300 may include a communication interface 302, a locationmodule 304, a processor 306, and data storage 308. All of the componentsillustrated in FIG. 3 may be linked or coupled together by acommunication link or bus 310 (e.g., a wired or wireless link). Theserver 300 may also include hardware to enable communication within theserver 300 and between the server 300 and another computing device (notshown). The hardware may include transmitters, receivers, and antennas,for example.

The communication interface 302 may allow the server 300 to communicatewith another device (not shown), such as a mobile phone, personalcomputer, etc. Thus, the communication interface 302 may be configuredto receive input data from one or more computing devices, and may alsobe configured to send output data to the one or more computing devices.In some examples, the communication interface 302 may also maintain andmanage records of data received and sent by the server 300. In otherexamples, records of data may be maintained and managed by othercomponents of the server 300.

The location module 304 may be configured to receive data from a clientdevice and determine a geographic location of the client device. Thedetermination may be based on outputs of an accelerometer, gyroscope,barometer, magnetometer, or other sensors of the client device, as wellas based on location determinations of the client device. Further, thelocation module 304 may be configured to execute a dead reckoningalgorithm. Using a log of sensor data as inputs to the dead reckoningalgorithm, the location module 304 may determine an estimated trajectoryor pedestrian dead reckoning of the client device and associated user.

The location module 304 may also be configured to determine and store ahistory of sensor measurements of the client device for laterreprocessing based on updated data pertaining to networks or informationused to the determine the locations.

The data storage 308 may store program logic 312 that can be accessedand executed by the processor 306. The data storage 310 may also includea location database 314 that can be accessed by the processor 306 aswell, for example, to retrieve information regarding wireless accesspoints, magnetic field data, orientation data, locations of satellitesin a GPS network, floor plans of a building, etc., or any other type ofinformation useful for determining a location of a client device.

The server is illustrated with a second processor 316, which may be anapplication specific processor for input/output functionality. In otherexamples, functions of the processor 306 and the processor 316 may becombined into one component.

Within examples, measurements collected from various sensors of a device(such as WIFI components, GPS sensors, barometers, and inertial sensors)can be combined with information from external databases (such as knownlocations of WIFI access points or building floor plans) to estimate alocation or movement of the device in real-time. Recording the real-timelocation estimate at all times (or intervals/increments of time) mayalso produce a location history.

III. Example Methods and Functionality

FIG. 4 is a flow diagram illustrating an example method for determininga location or movement of a device. Initially, computing device(s) 400,operated by users 402 or surveyors 404, may traverse areas in anenvironment and output traces to a model builder 406. A device operatedby a user 402 may output traces passively (e.g., the device may beconfigured to output the trace data with no additional user input),including raw data output by sensors of the device like WIFI scans, GPSdata, accelerometer data, gyroscope data, barometer readings,magnetometer data, etc. Each trace may be associated with a time thedata was collected, and thus, for traces that include GPS data, otherdata in the traces also has location-specific references. A deviceoperated by a surveyor 404 may have location-specific references for alltraces, whether due to associated GPS data or manual input of locationinformation.

The model builder 406 may be a module on a computing device or server,and may be configured to generate a model of the environment based onthe received traces. The model builder 406 may include a trace localizerand a map builder. The model builder 406 may access reference data orinformation, such as magnetic field signal strength data in theenvironment at specific locations in the environment, or other landmarkdata of the environment, such as strength of signal (RSSI) for WIFIaccess points. The model builder 406 may be configured to generate a mapor path of the device based on the traces. In one example, the modelbuilder 406 may utilize GPS data to determine locations of the deviceover time, utilize dead reckoning (based on accelerometer and gyroscopeoutputs) to project a path, utilize elevational data (such as based onGPS elevational data and barometer readings), and optimize the path byjointly combining each. The model builder 406 may further optimize thepath to match magnetic field data to reference magnetic field maps toalign a path that most likely resembles a path that the device traversedthrough the environment.

A location provider 408 may access a model output by the model builder406 to determine locations of other device(s) 410 based on providedpassive traces as well. Within examples, the location provider 408 mayreturn a location of the device or an estimation of movement of thedevice to the device 410 based on data received in the traces. Thecomputing device may use the determined locations to present a map on adisplay of the device, for example, and show a device location on themap, or otherwise generate information and instructions for providingsuch a display. The location of a device may also be used inlocation-based services, such as to narrow an Internet search to an areathat is nearby the device location, to personalize “local” news and/orweather updates or information sent to the device, to direct emergencycalls (e.g., 911 call-services) to an appropriate or closest callhandling service, and the like.

Traces received from devices may include a variety of measurements frommultiple different sensors, and may include a variety of measurementscollected over time or at various locations. A trace may refer to asensor log or a collection of data output from sensors on the deviceover some time period and collected over a number of locations. Thesensors that output data may be selected, or data to be included withinthe sensor log may also be selected. In some examples, a trace of datamay include all data collected by a device (using a number of sensors)over a given time frame (e.g., about 5 seconds, or perhaps about 5minutes or any ranges therein or longer). Measurements in a trace orfrom trace to trace may be considered statistically independent.However, in instances in which the measurements are collected frompositions/locations in close proximity or collected close in time, themeasurements may have correlations.

The traces or logs of data may be used to build a magnetic fieldstrength map of the number of locations aligned to latitude andlongitude or position coordinates. Estimate magnetic field strengths canbe made based on known locations of where the magnetic field scansoccurred. The reverse is also true. To solve the problem when both areinitially unknown, a simultaneous localization and mapping (SLAM) can beperformed to solve both at the same time using received data in the logsof data. If one of a location of a magnetic field anomaly or locationsof magnetic field scans are known, then the known data can be heldconstant while optimizing the other. The received logs of data can beused to determine relative paths traversed by the devices using deadreckoning, which provides estimates of AP locations and trajectory ofthe devices relative to each other, and such relative estimates can bealigned with more absolute positions using measurements from GPS.However, GPS generally provides accurate latitude and longitudemeasurements, but only in certain locations (mostly outdoors).

Additional or alternative maps of signals or signal strengths may alsobe generated based on received logs of data or accessed to localize adevice. Such maps include WIFI strength of signal (RSSI) maps, Bluetoothdevice maps, or geographic walkway and street maps, for example.

Thus, within examples, trustworthy measurements in an absolute frame canbe accessed first to generate a first estimate of a magnetic fieldstrength map, and new measurements and new sensor logs can be introducedto refine the estimate using the estimate as a starting point to buildupon. As each new piece of data is introduced, a current estimate isheld constant and used to determine an initial estimate for the newdata. Then, a SLAM optimization may be performed to jointly optimize alldata without keeping anything constant. Iterations may be performeduntil all data has been considered.

FIG. 5 is a block diagram of an example method in accordance with atleast some embodiments described herein. Method 500 shown in FIG. 5presents an embodiment of a method that, for example, could be used withthe system 100 in FIG. 1, the device 200 in FIG. 2, the server 300 inFIG. 3, and/or the method in FIG. 4, for example, or may be performed bya combination of any components or processes of FIGS. 1-4. Method 500may include one or more operations, functions, or actions as illustratedby one or more of blocks 502-516. Although the blocks are illustrated ina sequential order, these blocks may in some instances be performed inparallel, and/or in a different order than those described herein. Inaddition, the various blocks may be combined into fewer blocks, dividedinto additional blocks, and/or removed based upon the desiredimplementation.

In addition, for the method 500 and other processes and methodsdisclosed herein, the flowchart shows functionality and operation of onepossible implementation of present embodiments. In this regard, eachblock may represent a module, a segment, or a portion of program code,which includes one or more instructions executable by a processor forimplementing specific logical functions or steps in the process. Theprogram code may be stored on any type of computer readable medium, forexample, such as a storage device including a disk or hard drive. Thecomputer readable medium may include a non-transitory computer readablemedium, for example, such as computer-readable media that stores datafor short periods of time like register memory, processor cache andRandom Access Memory (RAM). The computer readable medium may alsoinclude non-transitory media, such as secondary or persistent long-termstorage, like read only memory (ROM), optical or magnetic disks,compact-disc read only memory (CD-ROM), for example. The computerreadable media may also be any other volatile or non-volatile storagesystems. The computer readable medium may be considered a computerreadable storage medium, a tangible storage device, or other article ofmanufacture, for example.

In addition, for the method 500 and other processes and methodsdisclosed herein, each block in FIG. 5 may represent circuitry and/orother hardware that is wired or otherwise configured to perform thespecific logical functions and processes of method 500.

Functions of the method 500 may be fully performed by a computing device(or components of a computing device such as one or more processors), ormay be distributed across multiple computing devices and/or a server. Insome examples, the computing device may receive information from sensorsof the computing device, or where the computing device is a server theinformation can be received from another device that collects theinformation.

At block 502 of FIG. 5, a computing device, such as one or more of theclient devices and/or servers discussed herein, estimates an orientationof a client device (e.g., a phone) by computing a rotation from acoordinate frame of a client device (e.g., device frame) to a coordinateframe of the earth (e.g., world frame). This rotation from the deviceframe to the world frame is identified as R_(device) ^(world).

Referring to FIG. 6, for example, a world frame 600 may be defined by anXYZ-coordinate frame, with the positive X-axis extending east, thepositive Y-axis extending north, and the positive Z-axis extending up(e.g., directed radially away from the center of the earth). Generally,the world frame 600 varies depending on the location of a client device602 and an associated user 604 on the earth. However, the world frame600 may be considered fixed over a relatively short period of time, suchas one day, because the variation of the world frame 600 based on theuser's steps is likely insignificant. In other examples, the world framemay be allowed to drift over time.

Further, FIG. 6 shows a device frame 606 that may be defined by anXYZ-coordinate frame, with the positive X-axis extending to the rightwith respect to a front face of the device 602, the positive Y-axisextending up with respect to the front face of the device, and thepositive Z-axis extending perpendicularly out of the front face of thedevice. FIG. 6 also illustrates a user frame 608 that may be defined byan XYZ-coordinate frame, with the X-axis extending in front of and awayfrom the user 604, the Y-axis extending to the left of the user, and theZ-axis extending up from the user.

At block 502, the computing device computes the rotation R_(device)^(world) to relate the device frame 606 to the world frame 600. Thecomputing device may estimate the rotation _(device) ^(world) by fusingdevice sensor data. The device sensor data may be collected by theclient device over a plurality of locations and over a time period, andmay include accelerometer and gyroscope data, and in some cases,magnetometer data. The magnetometer data, for instance, may be used tocompensate for a bias effect of the gyroscope. In one example, thecomputing device may estimate the rotation R_(device) ^(world) byperforming an extended kalman filter (EKF) method using the devicesensor data. Alternatively or in conjunction, the computing device mayestimate the rotation R_(device) ^(world) using a game rotation vectordefined by Android open source software.

At block 504, the computing device selects data, such as device sensordata related to the rotation R_(device) ^(world) or the rotation itself,for further processing in the present method 500. In one example, atblock 504, the computing device selects time slices during which anaverage orientation of the device relative to the user does not changeor changes within a predetermined range. In one example, the time slicesare selected by processing the rotation R_(device) ^(world), andidentifying when the orientation of “world_down” in the device framedoes not change significantly between time slices, such as by less thanabout 35 degrees. At block 504, the computing device may eliminatepotentially unreliable data associated with large variations in theorientation of the device, which may occur when a user takes their phoneout of their pocket, for example. Consequently, the computing device atblock 504 may then select more reliable orientation data for furtherprocessing.

At block 506, the computing device estimates an average orientation ofthe device relative to the user by computing a rotation from an averagegravity aligned (AGA) frame to the device frame. This rotation from AGAframe to the device frame is identified as a rotation R_(AGA) ^(device).The computing device may use the orientation data selected at block 504to compute the rotation R_(AGA) ^(device), which may help to verify anassumption that the device is in a generally static position relative tothe user.

In one example, the computing device performs the calculation of block506 by creating a coordinate average gravity aligned (AGA) frame that isfixed relative to the device coordinate frame, and then computing therotation from the AGA frame to the device frame. Generally, thecomputing device defines the AGA frame such that the Z-axis, onceaveraged, aligns generally with the Z-axis of the world frame. In oneexample, the client device measures the average gravity, whichcorrelates to the negative-Z-axis and provides information regarding thedown direction (e.g., directed radially toward the center of the earth).The computing device may then rotate the measured average gravity 180degrees to generally align the average gravity with the positive-Z-axisof the world frame. FIG. 6 illustrates an example AGA frame 610 that maybe defined by an XYZ-coordinate frame, with the positive Z-axisextending upwardly similar to the Z-axis of the world frame 600. Inpractice, the Z-axis of the AGA frame does not align precisely with theZ-axis of the world frame, because the world frame is not fixed withrespect to the device and the device moves with respect to the worldframe. The X and Y-axes of the AGA frame are orthogonal to each otherand to the Z-axis, but otherwise the X and Y-axes may be definedarbitrarily.

For instance, at block 506, the computing device may use the followingEquation 1 to define the AGA frame:

AGA_z_in_device_frame=normalize(average(measured_acceleration_in_device_frame))  (1)

In Equation 1, an accelerometer of the client device may provide themeasured_acceleration_in_device_frame data. In another example, at block506, the computing device may use the following Equation 2 to define theAGA frame:

AGA_z_in_device_frame=normalize(average(world_z_in_device_frame))  (2)

In Equation 2, the computing device may determine theworld_z_in_device_frame data from an estimate of the orientation of thedevice relative to the real world according to Equation 3:

R_(world) ^(device)*(0, 0, 1)  (3)

In this example, an AGA_x vector is selected to be perpendicular to anAGA_z vector, but otherwise may be selected arbitrarily by picking twonon-collinear vectors, computing their cross product with AGA_z, andpicking the normalization of the largest result. At block 506, once thecomputing device defines the AGA frame, the computing device may thencompute the rotation R_(AGA) ^(device) from the AGA frame to the deviceframe. In the present example, this rotation R_(AGA) ^(device) remainsconstant for each time slice selected at block 504.

At block 508, the computing device may perform step detection usingconventional techniques to determine steps taken by a user associatedwith the client device. Generally, the computing device may perform thestep detection based on accelerometer and gyroscope outputs thatcorrespond to typical step motions.

At block 510, for one or more (or each) step detected at block 508, thecomputing device estimates changes in orientation of the user. In oneexample, at block 510, the computing device projects the AGA frame to ahorizontal plane to provide a horizontally projected AGA (HPAGA) frame.An X-axis of the HPAGA frame may be used to represent the orientation ofthe user. The HPAGA frame corresponds to the AGA frame when the Z-axisof the AGA frame is aligned with the Z-axis of the world frame. FIG. 6illustrates such an HPAGA frame 612.

Further, at block 510, the computing device determines a rotation fromthe HPAGA frame to the AGA frame. This rotation is identified asR_(HPAGA) ^(AGA). The computing device may compute R_(HPAGA) ^(AGA) asthe shortest rotation that transforms the Z-axis of the world frame intothe Z-axis of the AGA frame. This rotation may vary over time, as theAGA frame moves over time.

In one example, the computing device at block 510 also computes arotation from the world frame to the HPAGA frame. This rotation may beidentified as R_(world) ^(HPAGA), and may be computed by the chain rule,such as in Equation 4 using the AGA frame and the device frame:

R _(world) ^(HPAGA) =R _(AGA) ^(HPAGA) *R _(device) ^(AGA) *R _(world)^(device)  (4)

The computing device may compute the rotations in Equation 4 once eachof the respective rotations are determined.

The computing device may then use the rotation R_(world) ^(HPAGA) todetermine the change in orientation of the user from one detected stepto another. In one example, the computing device determines this changein orientation of the user, or delta_theta, by comparing a user_yawvalue between different steps. The computing device may compute theuser-yaw value according to Equation 5:

user_yaw=a tan 2(HPAGA_x_in_world_frame.x,HPAGA_x_in_world_frame.y)+N  (5)

Equation 5 includes a constant value N, because the orientation of theuser with respect to the device is not known. The computing devicedetermines delta_theta by comparing the user_yaw between differentsteps, at which time the constant values N cancel out. For instance, thecomputing device may determine delta_theta between a first step s1 and asecond step s2 using Equation 6:

delta_theta=user_yaw_step(s2)−user_yaw_step(s1)  (6)

At block 512, the computing device may smooth the orientation estimatedetermined at block 510 to remove oscillations in orientation due to thehuman body zigzagging when each step is taken. The computing device mayperform this smoothing by window averaging the orientation (user_yaw)and/or orientation changes (delta_theta) with a window size of twosteps, for example. This example window averaging modifies theorientation estimate for each step to be the average between a presentstep and a previous step.

In FIG. 5, at block 514, the computing device may compute the rotationfrom the device frame to the HPAGA frame. The computing device mayperform this computation each time the orientation of the device isrequested (such as when magnetometer measurements are generated). In oneexample, the computing device may use the chain rule of Equation 7 todetermine R_(device) ^(HPAGA).

R _(device) ^(HPAGA) =R _(world) ^(HPAGA) *R _(device) ^(world)  (7)

Generally, this rotation encapsulates small movements in the device'sorientation that are not due to changes in the heading of the user.

At block 516, the computing device may then perform a loose coupling orSLAM optimization, using as measurements, one or more of: pedestriandead reckoning that is computed using data related to steps and changesin orientation of the user (e.g., user_yaw or delta theta values, whichmay be smoothed at block 512 or not), as computed herein; WIFI signalsin conjunction with WIFI environment information (such as WIFI RSSIfingerprint maps, or where WIFI access points are located and theassociated signal strength of the access points, or information measuredby devices from other users in the area); Bluetooth low energy (BLE) orother radio-frequency signals, used similarly to Wi-Fi signals; and/ormagnetic field measurements. At block 516, the computing device uses oneor more of these measurements (and/or perhaps others) in a SLAMoptimization to determine a position and location of the device anduser. In one example, at block 516, the computing device also performsthe optimization to help refine estimates of different rotations orparameters. In the case where a map of the environment is known, SLAMcan be replaced by a localization-only algorithm.

At block 516 (or after block 516), the computing device may use thedetermined location to present a map on a display, and show a devicelocation on the map, or otherwise generate information and instructionsfor providing such a display. The location of a device may also be usedin location-based services or computer applications, such as to narrowan Internet search to an area that is nearby the device location, topersonalize “local” news and/or weather updates or information sent tothe client device, to direct emergency calls (e.g., 911 call-services)to an appropriate or closest call handling service, to direct emergencyservices to help locate the client device in case of emergency, and thelike.

FIG. 7 provides a block flow diagram that summarizes the frames,rotations, parameters, estimations, and/or computations described abovein relation to FIG. 5. For instance, a block 702 represents thecomputation of the rotation R_(device) ^(world) from the device frame606 to the world frame 600. A block 704 represents the computation ofthe rotation R_(AGA) ^(device) from the AGA frame 610 to the deviceframe 606. As shown in FIG. 7, the computation at block 704 may use therotation R_(device) ^(world) to compute the rotation R_(AGA) ^(device).

Further, FIG. 7 includes a block 706 that represents the computation ofthe rotation R_(HPAGA) ^(AGA) from the HPAGA frame 612 to the AGA frame610. FIG. 7 shows that computation at block 706 may use the frameR_(AGA) ^(device) to compute the rotation R_(HPAGA) ^(AGA). FIG. 7 alsoincludes a block 708 that represents the computation of the rotationR_(world) ^(HPAGA) from the world frame 600 to the HPAGA frame 612. Asshown in FIG. 7, the computation at block 708 may use the framesR_(device) ^(world), R_(AGA) ^(device), and R_(HPAGA) ^(AGA) to computethe rotation R_(world) ^(HPAGA) using the chain rule.

In addition, FIG. 7 includes a block 710 that represents the computationof changes in the orientation of a user (delta_theta), which alsorelates to a rotation R_(world) ^(user) from the world frame 600 to theuser frame 608, and to a rotation R_(world) ^(HPAGA). As a generalmatter, it should be understood that a rotation R_(B) ^(C) from a frameB to a frame C is the inverse of a rotation R_(C) ^(B) from the frame Cto the frame B.

FIG. 8 is a block diagram of an example method 800 that may be used toperform the optimization 516 of FIG. 5. Generally, the method 800 may beimplemented similarly as described above with respect to the method 500,including performing the various blocks in a different order and/or inparallel.

In method 800, at block 802, the computing device retrieves or otherwiseaccesses a rotation from HPAGA to the device, or R_(HPAGA) ^(device).The computing device may compute the rotation R_(HPAGA) ^(device) usingthe HPAGA frame and the device frame discussed above. In one example,the rotation R_(HPAGA) ^(device) is computed as the inverse of therotation R_(device) ^(HPAGA), which may have been computed at block 516of the method 500.

At block 804, the computing device defines a parameteruser_heading_in_HPAGA that represents a yaw difference between the HPAGAframe and the user frame. Generally, R_(user) ^(HPAGA) is a rotationabout the Z-axis by an angle of -user_heading_in_HPAGA (a rotation bythe negative angle). The computing device may initially estimate theparameter user_heading_in_HPAGA, and later refine this parameter duringoptimization.

At block 806, the computing device defines a parameterHPAGA_yaw_in_world that represents a yaw difference between the HPAGAframe and the world frame. Generally, R_(HPAGA) ^(world) is a rotationabout the Z-axis by an angle of -HPAGA_yaw_in_world (a rotation by thenegative angle). The computing device may initially estimate theparameter HPAGA_yaw_in_world and may refine this parameter during theoptimization. In practice, the parameter HPAGA_yaw_in_world varies asfunction of time, because the HPAGA frame moves relative to the worldframe. In another implementation, the yaw of the rotation between twodifferent frames can be estimated as a parameter. For example, theparameter can represent the rotation between the user and the worldinstead of the rotation between the HPAGA frame and the world frame.Because of the chain rule, this is mathematically equivalent.

At block 808, the computing device determines pedestrian dead reckoningdata of the user of the client device. The computing device maydetermine or compute the pedestrian dead reckoning, which may beidentified as R_(user) ^(world), according to the following Equation 8and the different rotations discussed above:

R _(user) ^(world) =R _(device) ^(world) *R _(AGA) ^(device) *R _(HPAGA)^(AGA) *R _(user) ^(HPAGA)  (8)

Equation 8 is also equivalent to Equation 9:

R _(user) ^(world) R _(HPAGA) ^(world) *R _(user) ^(HPAGA)  (9)

The computing device may further optimize the computation of thepedestrian dead reckoning R_(user) ^(world) by using the delta_thetavalues discussed above as further constraints to the computation.

At block 810, the computing device processes measured magnetic fielddata to determine the magnetic field in the world frame. In the presentexample, the computing device processes the magnetic field data byrotating the data into the world frame according to a rotationR_(device) ^(world) computed by Equation 10:

R _(device) ^(world) =R _(user) ^(world) *R _(HPAGA) ^(user) *R_(device) ^(HPAGA)  (10)

Equation 10 is also equivalent to Equation 11:

R _(device) ^(world) =R _(HPAGA) ^(world) *R _(device) ^(HPAGA)  (11)

In this example, the rotation R_(device) ^(world) is used to rotate themeasured magnetic field in order to use the 3-D components of themagnetic field data. In addition, R_(device) ^(HPAGA) may be obtainedfrom the chain rule of Equation 12:

R _(device) ^(HPAGA) =R _(AGA) ^(HPAGA) *R _(device) ^(AGA)  (12)

Other variations to the equations discussed herein are also possibledepending, in part, on how the parameters are being defined and onconversions using the chain rule.

At block 812, the computing device may perform an optimization usingSLAM algorithms, such as GraphSLAM or FastSLAM, and/or in onlinelocalizations using other fusion algorithms, such as kalman filters. Inone example, at block 812, the computing device uses the pedestrian deadreckoning data to fuse available GPS data, WIFI data, and/or Bluetoothscan data. The computing device may then use the resulting fused data asadditional constraints in the optimization to identify differentparameters, such as a location and map of the client device and otherestimated rotations of the device.

FIG. 9 provides a block flow diagram that summarizes the frames,rotations, parameters, computations, and/or estimations described abovein relation to FIG. 8. For instance, a block 902 represents thecomputation of the rotation R_(device) ^(HPAGA), which may have beencomputed before the optimization at blocks 516 or 812. A block 904represents the estimation or definition of the parameteruser_heading_in_HPAGA, which represents the difference in yaw betweenthe HPAGA frame 612 and the user frame 608. In FIG. 9, a block 906represents the estimation or definition of the parameterHPAGA_yaw_in_world, which represents the difference in yaw between theHPAGA frame 612 and the world frame 600.

Further, a block 908 represents the computation of a rotation R_(user)^(world) from the user frame 608 to the world frame 600. The rotationR_(user) ^(world) may be obtained using a chain rule calculation throughHPAGA rotations. For example, the rotation R_(user) ^(world) may becomputed using Equations 8 or 9 above. As illustrated, the computationat block 908 may utilize delta-theta values that correspond touser_heading_in_HPAGA and/or HPAGA_yaw_in_world as constraints to helpestimate the rotation R_(user) ^(world). The rotation R_(user) ^(world)may then be used as the user orientation with respect to the world todetermine pedestrian dead reckoning data. In addition, this pedestriandead reckoning data may be used to fuse other data or constraints, suchas data from GPS, WIFI, and/or Bluetooth sensors.

In FIG. 9, a block 910 represents the computation of a rotationR_(world) ^(device) from the world frame 600 to the device frame 606.The rotation R_(world) ^(device) may be obtained using a chain rulecalculation through HPAGA rotations. For example, the rotation R_(world)^(device) may be computed using Equations 10 or 11 above. Asillustrated, the computation at block 910 may utilize delta-theta valuesthat correspond to HPAGA_yaw_in_world and a rotation R_(device) ^(HPAGA)as constraints to help estimate the rotation. The rotation R_(world)^(device) may then be used fuse magnetometer data associated with aclient device.

FIG. 10 is a block diagram that conceptually illustrates an examplesystem 1000 for determining locations. Any of the blocks in the system1000 may be modules, processors, or other devices, or may take the formof instructions executable by processors to perform the associatedfunction. The system 1000 may utilize the methods and processesdescribed herein to perform one or more of the following calculationsand optimizations.

In the system 1000, logs of data 1002 are received from devices. Thelogs of data may include GPS, RSSI, magnetometer, accelerometer, andgyroscope data with associated timestamps as collected by respectivedevices. The logs of data for which a dead reckoning and GPS locationagree may be provided to a non-linear least squares optimizer 1004, forexample. Logs of data for which a dead reckoning and GPS location do notagree may be rejected as erroneous data or data with too much noise. Thenon-linear least squares optimizer 1004 may optimize paths using GPS anddead reckoning, as shown at block 1006 and as described above using forexample a ceres optimizer, and then build optimal WIFI maps whilekeeping the paths constant, as shown at block 1008. The non-linear leastsquares optimizer 1004 may further jointly optimize paths and WIFI mapsusing a SLAM optimization and output a WIFI map, as shown at block 1010.

Traces with unreliable GPS data (at block 1012) may be received at ahierarchical Viterbi processor 1014 to perform a global search for mostlikely paths given associated WIFI scans in the traces, as shown atblock 1016. As an example, a path of a user trace may be determinedusing the Viterbi algorithm (e.g., most likely path through a graph)based on one or more of motion probabilities from dead reckoning,transition probabilities from floorplan, or emission probabilities froma WIFI model. The non-linear least squares optimizer 1004 may receivethe output of the global search and align with the dead reckoning to aViterbi path, as shown at block 1018, and jointly optimize all paths andWIFI maps using a SLAM optimization, as shown at block 1020.

The SLAM optimization is performed iteratively on growing subsets ofstates and constraints to determine a location of a user when data wascollected based on all data collected. A first iteration uses subsets sothat a function minimized is convex. Running SLAM on these subsets givesan estimate of the state subset. This estimate is used for determiningthe next subsets to include and the initialization to use for the nextiteration. Thus, more constraints are added using a previousdetermination as a time starting point as the best prediction. Thesystem 1000 defines a process that selects states, optimizes the statesusing a non-linear least squares solver, and runs SLAM algorithms todetermine how to initialize the state for the next optimizationiteration.

Although examples are described as determining a WIFI signal strengthmap, similar or same functions may be performed to determinelocalization of passively collected traces for creation of other typesof maps, such as magnetometer maps.

It should be understood that arrangements described herein are forpurposes of example only. As such, those skilled in the art willappreciate that other arrangements and other elements (e.g. machines,interfaces, functions, orders, and groupings of functions, etc.) can beused instead, and some elements may be omitted altogether according tothe desired results. Further, many of the elements that are describedare functional entities that may be implemented as discrete ordistributed components or in conjunction with other components, in anysuitable combination and location, or other structural elementsdescribed as independent structures may be combined.

While various aspects and embodiments have been disclosed herein, otheraspects and embodiments will be apparent to those skilled in the art.The various aspects and embodiments disclosed herein are for purposes ofillustration and are not intended to be limiting, with the true scopebeing indicated by the following claims, along with the full scope ofequivalents to which such claims are entitled. It is also to beunderstood that the terminology used herein is for the purpose ofdescribing particular embodiments only, and is not intended to belimiting.

What is claimed is:
 1. A method comprising: receiving, by one or moreprocessors of a computing device, a stream of sensor measurements madeby a client device coupled to a user; based on the sensor measurements,determining, by the one or more processors, a first angle of rotationbetween a client device coordinate frame defined with respect to theclient device and a world coordinate frame defined with respect toEarth; determining, by the one or more processors, an average gravityaligned (AGA) coordinate frame, wherein a z-axis of the AGA coordinateframe approximates a z-axis of the world coordinate frame; determining,by the one or more processors, a second angle of rotation between theAGA coordinate frame and the client device coordinate frame; detecting,by the one or more processors, two or more steps taken by the user whilethe client device is coupled to the user, wherein the step detection isbased on accelerometer and gyroscope measurements made by the clientdevice, and wherein the accelerometer and gyroscope measurements areincluded in the sensor measurements; based on the first angle ofrotation and the second angle of rotation, determining, by the one ormore processors, a change in orientation of the user from a firstdetected step of the user to a second detected step of the user; andbased on the first detected step of the user, the second detected stepof the user, and the change in orientation of the user, determining, bythe one or more processors, a location estimate of the client device. 2.The method of claim 1, wherein the computing device is the clientdevice.
 3. The method of claim 1, wherein the first angle of rotation isbased on sensor fusion of the accelerometer measurements and thegyroscope measurements.
 4. The method of claim 3, wherein the firstangle of rotation is based on sensor fusion of the accelerometermeasurements, the gyroscope measurements, and magnetometer measurements.5. The method of claim 1, wherein the AGA coordinate frame is definedwith respect to an average of gravity measurements made by the clientdevice, and wherein the gravity measurements are included in the sensormeasurements.
 6. The method of claim 1, wherein determining the firstangle of rotation comprises: determining a plurality of instances of thefirst angle of rotation over a period of time; and selecting instancesof the first angle of rotation from the plurality of instances such thatthe selected instances of the first angles of rotation are within apre-determined angle of one another.
 7. The method of claim 6, whereindetermining the AGA coordinate frame comprises determining the AGAcoordinate frame using the selected instances of the first angle ofrotation, and not using the non-selected instances of the first angle ofrotation.
 8. The method of claim 1, wherein determining the change inorientation of the user from the first detected step of the user to thesecond detected step of the user comprises: projecting the AGAcoordinate frame to a horizontal plane to provide a horizontallyprojected AGA (HPAGA) coordinate frame; determining a third angle ofrotation between the AGA coordinate frame and the HPAGA coordinateframe; based on the first angle of rotation, the second angle ofrotation, and the third angle of rotation, determining a fourth angle ofrotation between the HPAGA coordinate frame and the world coordinateframe; and based on the fourth angle of rotation, calculating the changein orientation of the user from the first detected step of the user tothe second detected step of the user.
 9. The method of claim 8, whereincalculating the change in orientation of the user from the firstdetected step of the user to the second detected step of the usercomprises: based on the fourth angle of rotation, determining a yawcomponent of the user between the first detected step of the user to thesecond detected step of the user; and smoothing the yaw component of theuser.
 10. The method of claim 9, wherein determining the locationestimate of the client device comprises calculating the locationestimate of the client device based on the yaw component of the user.11. The method of claim 1, further comprising: causing the client deviceto display the location estimate of the client device on a graphicalrepresentation of a map.
 12. A non-transitory computer-readable mediumhaving stored therein instructions, that when executed by one or moreprocessors of a computing device, cause the computing device to performoperations comprising: receiving a stream of sensor measurements made bya client device coupled to a user; based on the sensor measurements,determining a first angle of rotation between a client device coordinateframe defined with respect to the client device and a world coordinateframe defined with respect to Earth; determining an average gravityaligned (AGA) coordinate frame, wherein a z-axis of the AGA coordinateframe approximates a z-axis of the world coordinate frame; determining asecond angle of rotation between the AGA coordinate frame and the clientdevice coordinate frame; detecting two or more steps taken by the userwhile the client device is coupled to the user, wherein the stepdetection is based on accelerometer and gyroscope measurements made bythe client device, and wherein the accelerometer and gyroscopemeasurements are included in the sensor measurements; based on the firstangle of rotation and the second angle of rotation, determining a changein orientation of the user from a first detected step of the user to asecond detected step of the user; and based on the first detected stepof the user, the second detected step of the user, and the change inorientation of the user, determining a location estimate of the clientdevice.
 13. The non-transitory computer-readable medium of claim 12,wherein the first angle of rotation is based on sensor fusion of theaccelerometer measurements and the gyroscope measurements.
 14. Thenon-transitory computer-readable medium of claim 12, wherein the AGAcoordinate frame is defined with respect to an average of gravitymeasurements made by the client device, and wherein the gravitymeasurements are included in the sensor measurements.
 15. Thenon-transitory computer-readable medium of claim 12, wherein determiningthe first angle of rotation comprises: determining a plurality ofinstances of the first angle of rotation over a period of time; andselecting instances of the first angle of rotation from the plurality ofinstances such that the selected instances of the first angles ofrotation are within a pre-determined angle of one another.
 16. Thenon-transitory computer-readable medium of claim 15, wherein determiningthe AGA coordinate frame comprises determining the AGA coordinate frameusing the selected instances of the first angle of rotation, and notusing the non-selected instances of the first angle of rotation.
 17. Thenon-transitory computer-readable medium of claim 12, wherein determiningthe change in orientation of the user from the first detected step ofthe user to the second detected step of the user comprises: projectingthe AGA coordinate frame to a horizontal plane to provide a horizontallyprojected AGA (HPAGA) coordinate frame; determining a third angle ofrotation between the AGA coordinate frame and the HPAGA coordinateframe; based on the first angle of rotation, the second angle ofrotation, and the third angle of rotation, determining a fourth angle ofrotation between the HPAGA coordinate frame and the world coordinateframe; and based on the fourth angle of rotation, calculating the changein orientation of the user from the first detected step of the user tothe second detected step of the user.
 18. The non-transitorycomputer-readable medium of claim 17, wherein calculating the change inorientation of the user from the first detected step of the user to thesecond detected step of the user comprises: based on the fourth angle ofrotation, determining a yaw component of the user between the firstdetected step of the user to the second detected step of the user; andsmoothing the yaw component of the user.
 19. The non-transitorycomputer-readable medium of claim 18, wherein determining the locationestimate of the client device comprises calculating the locationestimate of the client device based on the yaw component of the user.20. A computing device comprising: a processor; memory; and programinstructions, stored in the memory, that upon execution by the processorcause the computing device to perform operations comprising: receiving astream of sensor measurements made by a client device coupled to a user;based on the sensor measurements, determining a first angle of rotationbetween a client device coordinate frame defined with respect to theclient device and a world coordinate frame defined with respect toEarth; determining an average gravity aligned (AGA) coordinate frame,wherein a z-axis of the AGA coordinate frame approximates a z-axis ofthe world coordinate frame; determining a second angle of rotationbetween the AGA coordinate frame and the client device coordinate frame;detecting two or more steps taken by the user while the client device iscoupled to the user, wherein the step detection is based onaccelerometer and gyroscope measurements made by the client device, andwherein the accelerometer and gyroscope measurements are included in thesensor measurements; based on the first angle of rotation and the secondangle of rotation, determining a change in orientation of the user froma first detected step of the user to a second detected step of the user;and based on the first detected step of the user, the second detectedstep of the user, and the change in orientation of the user, determininga location estimate of the client device.